Client-server systems provide electronic access by the client to data, information, accounts and other material stored at the server. In financial transactions, the system provides a client electronic access to accounts and financial resources.
In a client-server transaction, the client is required to prove to the server that it is an authentic client, and not some impersonator or other unauthorized party. Protocols are known by which a client proves to a server its authenticity, while at the same time it does not reveal information that could be misused by a third party.
A standard well known protocol for proving authenticity involves public-key cryptography. The client establishes a public key/private key pair and provides the public key to the server. In a transaction, to prove its authenticity to the server, the client forms a digital signature with its private key on a time-varying message, and the server verifies the digital signature with the client's public key. The time-varying message, which may be a timestamp or a challenge supplied by the server, is different in each instance. This message, when checked by the server, provides safeguards against a third party impersonating the client by simply replaying copies of previous signatures of the client that the third party has intercepted or otherwise acquired.
In the standard protocol described above, the server trusts that the public key belongs to the client, i.e., that the client is in fact actively involved in the transaction because it is presumed that only the client knows the private key and can form valid digital signatures. A convenient way to establish trust in a public key is to use a certificate. This is accomplished by a certification authority issuing public-key certificates signed with the certification authority's private key, which thereby asserts to the server that the client's public key is a valid public key issued by or registered with the certification authority. Assuming the server trusts the certification authority's public key, then it trusts the client's certificate, the client's public key and ultimately the client's authenticity.
With typical public-key cryptosystems, it is computationally expensive to form digital signatures because of the need to perform an exponentiation operation. In some electronic transactions, for example, those involving a smart card client where the computational capacity is limited, the standard protocol using a digital signature is computationally expensive and is therefore a significant burden.
Beller and Yacobi, in an article entitled "Fully-Fledged Two-Way Public Key Authentication and Key Agreement for Low-Cost Terminals" ELECTRONICS LETTERS, May 27, 1993, Vol. 29, No. 11, at pages 999-1000, describe a protocol that provides for less on-line computation on one side of the protocol. In this protocol authentication of the server by the client is carried out by the server sending a random challenge with an expected "colour", structure or format, to the client for verification by the client. Authentication of the client by the server is achieved by the client sending to the server its identity, public key, certificate and a signature on the random challenge for verification of the certificate and the signature by the server. The protocol is described as being useful where one side of the interaction is a low-cost customer device such as portable telephones, home banking terminals, smart cards and notebook computers.
Other protocols are known for establishing the authenticity of a client to a server. Client authentication protocols such as those based on secret-key cryptography exist, but often have the limitation that the server must be on-line, or the server must store a key which can be used to impersonate arbitrary clients. In Cellular Digital Packet Data systems, a client authenticates itself to a server by sending a one time password encrypted with a Diffie-Hellman shared key, and the server returns a new password for the next session. Again, the server must be on-line or the client must share a different password with each server, which can be inconvenient.